1
2
Далі
Немає.
JSON - це лише дані, і якщо ви додасте коментар, то це будуть також дані.
У вас може бути призначений елемент даних під назвою "_comment" (або щось інше), який слід ігнорувати програмами, які використовують дані JSON.
Ймовірно, вам було б краще мати коментар у процесах, що генерують / отримують JSON, оскільки вони повинні заздалегідь знати, якими будуть дані JSON, або, принаймні, їх структура.
Але якщо ви вирішили:
{
"_comment": "Текст коментаря йде сюди ...",
"глосарій": {
"title": "приклад глосарію",
"GlossDiv": {
"title": "S",
"GlossList": {
"GlossEntry": {
"ID": "SGML",
"SortAs": "SGML",
"GlossTerm": "Стандартна узагальнена мова розмітки",
"Скорочення": "SGML",
"Абрев": "ISO 8879: 1986",
"GlossDef": {
"para": "Мова мета розмітки, що використовується для створення мов розмітки, таких як DocBook.",
"GlossSeeAlso": ["GML", "XML"]
},
"GlossSee": "розмітка"
}
}
}
}
}
|
Ні, коментарі до форми // ... або / * ... * / заборонені в JSON. Ця відповідь базується на:
https://www.json.org
RFC 4627:
Тип носія / JSON для нотації об’єктів JavaScript (JSON)
RFC 8259 Формат обміну даними нотації об’єктів JavaScript (JSON) (суперцентри RFC 4627, 7158, 7159)
|
Додайте коментарі, якщо ви вирішите; видаліть їх за допомогою мініфікатора перед розбором або передачею.
Я щойно випустив JSON.minify (), який вилучає коментарі та пробіли з блоку JSON і робить дійсним JSON, який можна проаналізувати. Отже, ви можете використовувати це як:
JSON.parse (JSON.minify (my_str));
Коли я випустив його, я отримав величезну реакцію людей, які не погоджуються навіть з його ідеєю, тому я вирішив написати всебічне повідомлення в блозі, чому коментарі мають сенс у JSON. Він включає цей помітний коментар від творця JSON:
Припустимо, ви використовуєте JSON для збереження файлів конфігурації, які ви хотіли б анотувати. Вперед і вставте всі коментарі, які вам подобаються. Потім перенесіть його через JSMin перед тим, як передати його своєму парсеру JSON. - Дуглас Крокфорд, 2012
Сподіваємось, це корисно для тих, хто не згоден з тим, чому JSON.minify () може бути корисним.
|
Коментарі були видалені з JSON за задумом.
Я видалив коментарі з JSON, оскільки побачив, що люди використовували їх для проведення директив синтаксичного аналізу - практика, яка знищила б взаємодію. Я знаю, що відсутність коментарів засмучує деяких людей, але не повинно.
Припустимо, ви використовуєте JSON для збереження файлів конфігурації, які ви хотіли б анотувати. Вперед і вставте всі коментарі, які вам подобаються. Потім перенесіть його через JSMin перед тим, як передати його своєму парсеру JSON.
Джерело: Публічна заява Дугласа Крокфорда на G +
|
JSON не підтримує коментарі. Він також ніколи не був призначений для використання для конфігураційних файлів, де потрібні коментарі.
Hjson - це формат файлу конфігурації для людей. Розслаблений синтаксис, менше помилок, більше коментарів.
Див. Hjson.github.io для бібліотек JavaScript, Java, Python, PHP, Rust, Go, Ruby, C ++ та C #.
|
ЗАМОВЛЕННЯ: ВАША ГАРАНТІЯ НІЧНА
Як вже зазначалося, цей хак використовує переваги реалізації специфікації. Не всі аналізатори JSON зрозуміють такий JSON. Зокрема, потокові парсери задихнуться.
Цікавий курйоз, але ви насправді не повинні використовувати його ні для чого. Нижче - оригінальна відповідь.
Я знайшов невеликий хакер, який дозволяє розміщувати коментарі у файлі JSON, що не впливатиме на синтаксичний аналіз або будь-яким чином змінює представлені дані.
Схоже, що при оголошенні об'єктного літералу ви можете вказати два значення одним і тим же ключем, причому останнє має перевагу. Вірте чи ні, виявляється, що парсери JSON працюють однаково. Таким чином, ми можемо використовувати це для створення коментарів у вихідному JSON, які не будуть представлені в аналізованому поданні об’єкта.
({a: 1, a: 2});
// => Об'єкт {a: 2}
Object.keys (JSON.parse ('{"a": 1, "a": 2}')). Length;
// => 1
Якщо ми застосуємо цю техніку, ваш прокоментований файл JSON може виглядати так:
{
"api_host": "Ім'я хосту вашого сервера API. Ви також можете вказати порт.",
"api_host": "hodorhodor.com",
"retry_interval": "Інтервал у секундах між повторною спробою невдалих викликів API",
"повторний_інтервал": 10,
"auth_token": "Маркер автентифікації. Він доступний на інформаційній панелі розробника в розділі" Налаштування "",
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"favorite_numbers": "Масив, що містить мої улюблені числа за весь час",
"улюблені_номери": [19, 13, 53]
}
Наведений вище код є дійсним JSON. Якщо проаналізувати його, ви отримаєте такий об’єкт:
{
"api_host": "hodorhodor.com",
"повторний_інтервал": 10,
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"улюблені_номери": [19,13,53]
}
А це означає, що від коментарів немає сліду, і вони не матимуть дивних побічних ефектів.
Щасливого злому!
|
Подумайте про використання YAML. Це майже надмножина JSON (практично весь дійсний JSON є дійсним YAML), і він дозволяє коментувати.
|
Ви не можете. Принаймні, це мій досвід, швидко переглянувши json.org.
JSON має свій синтаксисвізуалізується на цій сторінці. Про коментарі немає жодної примітки.
|
Коментарі не є офіційним стандартом, хоча деякі аналізатори підтримують коментарі у стилі C ++. Я використовую JsonCpp. У прикладах є такий:
// Параметри конфігурації
{
// Кодування тексту за замовчуванням
"encoding": "UTF-8",
// Плагіни завантажуються під час запуску
"плагіни": [
"пітон",
"c ++",
"рубін"
],
// Розмір відступу вкладки
"відступ": {"довжина": 3, "use_space": true}
}
jsonlint не перевіряє це. Отже, коментарі - це розширення для парсера, а не стандартне.
Інший парсер - JSON5.
Альтернатива JSON TOML.
Наступною альтернативою є jsonc.
Остання версія nlohmann / json має необов’язкову підтримку ігнорування коментарів при розборі.
|
Натомість слід написати схему JSON. Схема JSON в даний час є запропонованою специфікацією проекту Інтернету. Окрім документації, схема також може бути використана для перевірки ваших даних JSON.
Приклад:
{
"description": "Людина",
"type": "об'єкт",
"властивості":
{
"ім'я":
{
"type": "рядок"
},
"вік":
{
"type": "ціле число",
"максимум": 125
}
}
}
Ви можете надати документацію, використовуючи атрибут схеми опису.
|
Якщо ви використовуєте Jackson як аналізатор JSON, тоді ви вмикаєте його, щоб дозволити коментарі:
ObjectMapper mapper = new ObjectMapper (). Configure (Feature.ALLOW_COMMENTS, true);
Тоді ви можете мати такі коментарі:
{
ключ: "значення" // Коментар
}
Ви також можете мати коментарі, починаючи з #, встановивши:
mapper.configure (Feature.ALLOW_YAML_COMMENTS, true);
Але загалом (як відповіли раніше) специфікація не дозволяє коментувати.
|
Ось те, що я знайшов у документації Google Firebase, що дозволяє розміщувати коментарі в JSON:
{
"//": "Деякі браузери використовуватимуть це, щоб увімкнути push-сповіщення.",
"//": "Це однаково для всіх проектів, це не ідентифікатор відправника вашого проекту",
"gcm_sender_id": "1234567890"
}
|
НЕМАЄ. Раніше JSON підтримував коментарі, але ними було зловживано та вилучено зі стандарту.
Від творця JSON:
Я видалив коментарі з JSON, оскільки побачив, що люди використовували їх для проведення директив синтаксичного аналізу - практика, яка знищила б взаємодію. Я знаю, що відсутність коментарів засмучує деяких людей, але не повинно. - Дуглас Крокфорд, 2012
Офіційний сайт JSON знаходиться на сайті JSON.org. JSON визначено стандартом ECMA International. Завжди існує процес подання клопотань про перегляд стандартів. Навряд чи анотації будуть додані до стандарту JSON з кількох причин.
JSON за дизайном - це легко реконструйована (аналізована людиною) альтернатива XML. Це спрощується навіть до такої міри, що анотації непотрібні. Це навіть не мова розмітки. Мета - стабільність та взаємодія.
Той, хто розуміє взаємозв'язок "має-є" об'єктної орієнтації, може зрозуміти будь-яку структуру JSON - у цьому вся суть. Це просто спрямований ациклічний графік (DAG) з тегами вузлів (пари ключ / значення), який є майже універсальною структурою даних.
Ця лише необхідна анотація може бути "// Це теги DAG". Назви ключів можуть бути настільки інформативними, наскільки це потрібно, дозволяючи довільну семантичну сутність.
Будь-яка платформа може проаналізувати JSON лише за допомогою декількох рядків коду. XML вимагає складних бібліотек OO, які не придатні для життя на багатьох платформах.
Анотації просто зробили б JSON менш оперативно сумісним. Просто більше нічого не можна додати, крім випадків, коли вам дійсно потрібна мова розмітки (XML), і неважливо, чи легко зберігати ваші збережені дані.
АЛЕ як зауважив творець JSON, завжди існувала підтримка конвеєру JS для коментарів:
Вперед і вставте всі коментарі, які вам подобаються.
Потім перенесіть його через JSMin перед тим, як передати його своєму парсеру JSON. - Дуглас Крокфорд, 2012
|
Якщо ваш текстовий файл, який є рядком JSON, буде прочитаний якоюсь програмою, наскільки складно було б вилучити коментарі стилю C або C ++ перед його використанням?
Відповідь: Це був би один лайнер. Якщо ви зробите це, тоді файли JSON можуть бути використані як файли конфігурації.
|
Якщо ви використовуєте бібліотеку Newtonsoft.Json з ASP.NET для читання / десеріалізації, ви можете використовувати коментарі до вмісту JSON:
// "name": "рядок"
// "id": int
або
/* Це
приклад коментаря * /
PS: Однорядкові коментарі підтримуються лише в 6+ версіях Newtonsoft Json.
Додаткова примітка для людей, які не можуть думати нестандартно: я використовую формат JSON для основних налаштувань у створеній мною веб-програмі ASP.NET Я читаю файл, перетворюю його в об'єкт налаштувань за допомогою бібліотеки Newtonsoft і використовую за необхідності.
Я вважаю за краще писати коментарі щодо кожного окремого параметра у самому файлі JSON, і мені насправді не байдуже про цілісність формату JSON, якщо бібліотека, якою я користуюся, у порядку.
Я думаю, що це «простіший у використанні / розумінні» спосіб, ніж створення окремого файлу «settings.README» та пояснення налаштувань у ньому.
Якщо у вас є проблеми з цим видом використання; вибачте, джин вийшов з лампи. Люди знайшли б інші звичаїФормат JSON, і ви нічого з цим не зробите.
|
Ідея JSON полягає у забезпеченні простого обміну даними між програмами. Вони, як правило, працюють в Інтернеті, а мова - JavaScript.
Це насправді не дозволяє коментарі як такі, однак передача коментаря як однієї з пар ім'я / значення в даних, безсумнівно, спрацює, хоча ці дані, очевидно, потрібно буде ігнорувати або обробляти спеціально кодом аналізу.
Все, що сказано, не в тому, що файл JSON повинен містити коментарі у традиційному розумінні. Це повинні бути просто дані.
Подивіться веб-сайт JSON, щоб отримати докладнішу інформацію.
|
JSON не підтримує коментарі спочатку, але ви можете створити власний декодер або принаймні препроцесор для видалення коментарів, це цілком нормально (якщо ви просто ігноруєте коментарі і не використовуєте їх для керівництва, як ваша програма повинна обробляти дані JSON ).
JSON не має коментарів. Кодер JSON НЕ ПОВИНЕН виводити коментарі.
Дешифратор JSON МОЖЕ приймати та ігнорувати коментарі.
Ніколи не слід використовувати коментарі для передачі чогось значущого. Це є
для чого призначений JSON.
Пор .: Дуглас Крокфорд, автор специфікації JSON.
|
Я просто стикався з цим для файлів конфігурації. Я не хочу використовувати XML (багатослівний, графічний, потворний, важкий для читання), формат "ini" (відсутність ієрархії, відсутність реального стандарту тощо) або формат "Властивості" Java (наприклад, .ini).
JSON може робити все, що може, але це набагато менш багатослівно і зручніше для читання - а парсери є простими та повсюдними на багатьох мовах. Це просто дерево даних. Але позасмугові коментарі часто необхідні для документування конфігурацій "за замовчуванням" тощо. Конфігурації ніколи не повинні бути "повними документами", а дерева збережених даних, які можуть бути зручні для читання у разі потреби.
Я думаю, можна було б використовувати "#": "коментар" для "дійсного" JSON.
|
Це залежить від вашої бібліотеки JSON. Json.NET підтримує коментарі у стилі JavaScript, / * comment * /.
Див. Інше запитання щодо переповнення стека.
|
JSON має великий сенс для конфігураційних файлів та іншого локального використання, оскільки він повсюдний і тому, що набагато простіший за XML.
Якщо у людей є вагомі причини проти коментарів у JSON при передачі даних (дійсних чи ні), то можливо JSON можна розділити на два:
JSON-COM: JSON на дроті або правила, які застосовуються при передачі даних JSON.
JSON-DOC: документ JSON або JSON у файлах або локально. Правила, що визначають дійсний документ JSON.
JSON-DOC дозволить коментувати, і можуть існувати інші незначні відмінності, такі як обробка пробілів. Синтаксичні аналізатори можуть легко перетворити з однієї специфікації на іншу.
Щодо зауваження Дугласа Крокфорда з цього приводу (посилання @Artur Czajka)
Припустимо, ви використовуєте JSON для збереження файлів конфігурації, які ви хотіли б анотувати. Вперед і вставте всі коментарі, які вам подобаються. Потім перенесіть його через JSMin перед тим, як передати його своєму парсеру JSON.
Ми говоримо про загальну проблему конфігураційного файлу (крос-мова / платформа), і він відповідає спеціальною утилітою JS!
Звичайно, специфічний JSON minify може бути реалізований будь-якою мовою,
але стандартизуйте це, щоб воно стало всюдисущим у парсерах на всіх мовах і платформах, щоб люди перестали витрачати свій час на відсутність цієї функції, оскільки вони мають хороші приклади використання, шукаючи проблему на форумах в Інтернеті та змушуючи людей говорити їм, що це погана ідея або припускаючи, що легко реалізувати вилучення коментарів із текстових файлів.
Інше питання - сумісність. Припустимо, у вас є бібліотека або API або будь-яка підсистема, яка має певні конфігураційні файли або файли даних, пов’язані з ними. І ця підсистема є
для доступу з різних мов. Тоді ви хочете сказати людям: до речі
не забудьте вилучити коментарі з файлів JSON, перш ніж передати їх парсеру!
|
Якщо ви використовуєте JSON5, ви можете включити коментарі.
JSON5 - це запропоноване розширення JSON, яке має на меті полегшити людям написання та ведення від руки. Це робиться шляхом додавання деяких мінімальних функцій синтаксису безпосередньо з ECMAScript 5.
|
Набір інструментів Dojo Toolkit для JavaScript (принаймні станом на версію 1.4) дозволяє включати коментарі до вашого JSON. Коментарі можуть мати формат / * * /. Набір інструментів Dojo використовує JSON через виклик dojo.xhrGet ().
Інші набори JavaScript можуть працювати аналогічно.
Це може бути корисно під час експериментів з альтернативними структурами даних (або навіть зі списками даних) перед вибором остаточного варіанту.
|
JSON не є оформленим протоколом. Це вільний від мови формат. Отже, формат коментаря не визначений для JSON.
Як припускають багато людей, є кілька хитрощів, наприклад, дублікати ключів або певний _комментар ключа, якими ви можете скористатися. Тобі вирішувати.
|
Ви можете мати коментарі в JSONP, але не в чистому JSON. Я щойно витратив годину, намагаючись змусити мою програму працювати з цим прикладом з Highcharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?
Якщо ви перейдете за посиланням, ви побачите
? (/ * AAPLісторичні дані OHLC з API Google Finance * /
[
/ * Травень 2006 * /
[1147651200000,67.79],
[1147737600000,64.98],
...
[1368057600000 456,77],
[1368144000000 452,97]
]);
Оскільки в моїй локальній папці був подібний файл, проблем із політикою того самого походження не було, тож я вирішив використовувати чистий JSON ... і, звичайно, $ .getJSON мовчки не працював через коментарі.
Зрештою я просто надіслав ручний HTTP-запит на вказану вище адресу і зрозумів, що тип вмісту - це текст / javascript, оскільки, ну, JSONP повертає чистий JavaScript. У цьому випадку коментарі дозволяються. Але моя програма повернула контент-тип application / json, тому мені довелося видалити коментарі.
|
Це питання "чи можете ви". І ось відповідь "так".
Ні, не слід використовувати дублікатні члени об’єкта для вкладання даних бічних каналів у кодування JSON. (Див. "Імена всередині об'єкта ПОВИННІ бути унікальними" у RFC).
І так, ви можете вставити коментарі навколо JSON, які ви можете проаналізувати.
Але якщо вам потрібен спосіб вставлення та вилучення довільних даних бічного каналу у дійсний JSON, ось відповідь. Ми використовуємо не унікальне представлення даних у кодуванні JSON. Це дозволено * у другому розділі RFC у розділі "пробіли дозволяються до або після будь-якого з шести структурних символів".
* RFC стверджує лише "пробіли допускаються до або після будь-якого з шести структурних символів", не згадуючи явно рядків, чисел, "false", "true" та "null". Цей пропуск ігнорується у ВСІХ реалізаціях.
По-перше, канонізуйте свій JSON, зменшивши його:
$ jsonMin = json_encode (json_decode ($ json));
Потім закодуйте свій коментар у двійковій формі:
$ hex = розпакувати ('H *', $ коментар);
$ commentBinary = base_convert ($ hex [1], 16, 2);
Потім увімкніть двійковий файл:
$ steg = str_replace ('0', '', $ commentBinary);
$ steg = str_replace ('1', "\ t", $ steg);
Ось ваш результат:
$ jsonWithComment = $ steg. $ jsonMin;
|
Застереження: це безглуздо
Насправді є спосіб додати коментарі та залишатися в межах специфікації (додатковий аналізатор не потрібен). Це не призведе до зручних для читання коментарів без будь-якого аналізу.
Ви можете зловживати наступним:
Незначний пробіл допускається до або після будь-якого маркера.
Пробіл - це будь-яка послідовність одного або декількох наступних кодів
точки: підведення символів (U + 0009), подача рядка (U + 000A), каретка
повернення (U + 000D) та пробіл (U + 0020).
Ви можете зловживати цим, щоб додати коментар. Наприклад: розпочніть та закінчіть свій коментар вкладкою. Кодуйте коментар у base3 та використовуйте інші пробіли, щоб представляти їх. Наприклад.
010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202
.
Це просто залишить у вас багато нечитабельних пробілів (якщо ви не зробите плагін IDE для кодування / декодування на льоту).
Я навіть ніколи не пробував цього, зі зрозумілих причин, і ви не повинні цього робити.
|
JSON не дозволяє коментарі як такі. Міркування є абсолютно безглуздими, тому що ви можете використовувати сам JSON для створення коментарів, який повністю усуває міркування, і завантажує простір даних парсера без поважних причин абсолютно з однаковими результатами та потенційними проблемами, такими як вони є: JSON файл із коментарями.
Якщо ви спробуєте помістити коментарі (наприклад, використовуючи // або / * * / або #), тоді деякі синтаксичні аналізатори не зможуть, оскільки це строго не
в межах специфікації JSON. Тож ніколи не слід цього робити.
Ось, наприклад, де моя система обробки зображень зберегла позначення зображень та деяку основну відформатовану (коментар) інформацію, що стосується їх (унизу):
{
"Позначення": [
{
"anchorX": 333,
"anchorY": 265,
"areaMode": "Еліпс",
"ступеніX": 356,
"ступіньY": 294,
"непрозорість": 0,5,
"text": "Еліптична область зверху",
"textX": 333,
"textY": 265,
"title": "Позначення 1"
},
{
"anchorX": 87,
"якірне": 385,
"areaMode": "Прямокутник",
"ступеніX": 109,
"ступіньY": 412,
"непрозорість": 0,5,
"text": "Площа виправлення \ не знизу",
"textX": 98,
"textY": 385,
"title": "Позначення 2"
},
{
"anchorX": 69,
"якірне": 104,
"areaMode": "Багатокутник",
"ступеніX": 102,
"ступіньY": 136,
"непрозорість": 0,5,
"pointList": [
{
"i": 0,
"х": 83,
"y": 104
},
{
"i": 1,
"х": 69,
"y": 136
},
{
"i": 2,
"х": 102,
"y": 132
},
{
"i": 3,
"х": 83,
"y": 104
}
],
"text": "Простий багатокутник",
"textX": 85,
"textY": 104,
"title": "Позначення 3"
}
],
"imageXW": 512,
"imageYW": 512,
"imageName": "lena_std.ato",
"tinyDocs": {
"c01": "Дані позначень зображень JSON:",
"c02": "-------------------------",
"c03": "",
"c04": "Ці дані містять позначення зображень та пов'язану область",
"c05": "інформація про вибір, яка забезпечує засіб для",
"c06": "галерея зображень для відображення позначень з еліптичним,",
"c07": "прямокутні, багатокутні або вільні позначення площі",
"c08": "над зображенням, яке відображається відвідувачеві галереї.",
"c09": "",
"c10": "Позиції X та Y на зображенніпростору. Зображення",
"c11": "роздільна здатність надається як imageXW та imageYW, які",
"c12": "ви використовуєте для масштабування областей позначень до їх належного",
"c13": "розташування та розміри для відображення зображення,",
"c14": "незалежно від масштабу.",
"c15": "",
"c16": "Для еліпсів якір є центром еліпса,",
"c17": "а екстенти - радіуси X та Y відповідно.",
"c18": "",
"c19": "Для прямокутників якорем є лівий верхній і",
"c20": "екстенти внизу праворуч.",
"c21": "",
"c22": "Для режимів від руки та багатокутника, pointList",
"c23": "містить ряд пронумерованих XY точок. Якщо область",
"c24": "закрито, остання точка буде такою ж, як",
"c25": "спочатку, отже, все, що вам потрібно, це малювання",
"c26": "рядки між точками у списку. Якір і протяжність",
"c27": "встановлені ліворуч і знизу праворуч від зазначеного",
"c28": "область, і може використовуватися як спрощений прямокутник",
"c29": "виявити для наведення курсора миші на ці типи",
"c30": "з областей.",
"c31": "",
"c32": "Текстові позиції та текстові позиції забезпечують базове розташування",
"c33": "інформація, яка допоможе вам знайти текстову інформацію",
"c34": "у розумному місці, пов'язаному з місцевістю",
"c35": "індикація.",
"c36": "",
"c37": "Непрозорість - це значення від 0 до 1, де .5 являє собою",
"c38": "50% непрозорий фон і 1.0 являє собою повністю непрозорий",
"c39": "задник. Рекомендація складати регіони",
"c40": "лише якщо користувач наводить вказівник на зображення,",
"c41": "і щоб був намальований текст, пов'язаний з регіонами",
"c42": "лише якщо користувач наводить вказівник на вказаний",
"c43": "регіон."
}
}
|
Для нашого проекту ми використовуємо strip-json-comments. Він підтримує щось на зразок:
/ *
* Опис
* /
{
// веселки
"єдиноріг": / * ❤ * / "торт"
}
Просто npm install --save strip-json-comments, щоб встановити та використовувати його, як:
var strip_json_comments = require ('strip-json-comments')
var json = '{/ * веселки * / "єдиноріг": "торт"}';
JSON.parse (strip_json_comments (json));
// => {єдиноріг: 'торт'}
|
У моєму випадку мені потрібно використовувати коментарі для цілей налагодження безпосередньо перед виведенням структури JSON. Тому я вирішив використовувати інформацію про налагодження в заголовку HTTP, щоб уникнути злому клієнта:
заголовок ("My-Json-Comment: Так, я знаю, що це обхідне рішення ;-)");
|
Щоб розрізати елемент JSON на частини, я додаю рядки "фіктивний коментар":
{
"#############################" : "Частина 1",
"data1": "значення1",
"data2": "значення2",
"#############################" : "Частина 2",
"data4": "значення3",
"data3": "value4"
}
|
1
2
Далі
Високоактивне запитання. Заробіть 10 репутації, щоб відповісти на це питання. Вимога про репутацію допомагає захистити це питання від спаму та відсутності відповідей.
Не відповідь, яку ви шукаєте? Перегляньте інші запитання, позначені коментарями json, або задайте власне запитання.